
AMENDMENTS 

Please amend the application as indicated hereafter. 



In the Specification 

Please delete the paragraph(s) of the specification identified below, and replace with the 
following clean copy paragraph(s). 



-Page 4, lines 1-3 

) FIG. 1 1 is a display diagram of a PIN entry screen subsequently to the rental options screen 

CJfrl ^ presented in FIG. 1 0 indicating that the selected MOD title is blocked because of its rating and providing a 
personal identification (PIN) entry to access the blocked MOD title. 
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-Page 8, lines 13-19 

The applications that are stored in the DRAM 44 may be applications that are loaded when the 
DHCT 16 initializes or are applications that are downloaded to the DHCT 16 upon a user-initiated command 
using an input device such as the remote 40. In this non-limiting example, as shown in FIG. 2, DRAM 44 
contains the following application clients: an e-mail application client 59, a digital music application client 
61, a service guide application 63 and a media-on-demand application client (MOD) 65 (discussed in more 
detail below). It should be clear that these applications are not limiting and merely serve as examples for this 
present embodiment of the invention. 



-Page 11, lines 26-33 



/V 3 Another signaling scenario supported by the present invention is the VOD content server 22 in- 

C^Ol^^^ progress scenario. FIG. 4F is a display diagram 1 10 depicting the MOD application server in progress 

request 1 1 1 message communicated from the VOD content server 22 to the DNCS 23. The DNCS 23 uses 
this message 111 as an audit mechanism to determine if it is in sync with the VOD content server 22. The 
MOD application server periodically sends this MOD application server session in progress message 1 1 1 to 
the DNCS 23. The message 1 1 1 contains a list of all active sessions for that MOD application server, and the 
DNCS 23 compares this list to its list of active sessions for that particular application server. The DNCS 23 
takes appropriate action if the lists do not match. 
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-Page 11, lines 34-37 through page 12, lines 1-3 



j^- U| The DNCS 23 periodically initiates a MOD application client session in progress request 1 14 as 

f ls' shown in scenario 1 13 in FIG. 4G. This message 1 14 is used to periodically inform the network 1 8 of the 

sessions that are active on a DHCT 1 6. The DNCS 23 uses this message as an audit mechanism to determine 
if it is in sync with the DHCT 16. The DHCT 16 periodically sends a client in session progress message (not 
shown). This message contains a list of all active sessions for the DHCT 16. The DNCS 23 compares this 
list to a list of active sessions for that DHCT 16 and takes appropriate action if the lists do not match. 



-Page 12, lines 4-14 



. 



The present invention permits the DHCT 16 to initiate a MOD session tear down scenario. FIG. 4H 
is a display diagram 1 18 depicting the procedure for tearing down a session using the client initiated session 
release scenario. A session that is active on that particular DHCT 16 may be torn down by the DCHT 16. 
The initiate this process, the DHCT 16 sends a MOD application client release request 1 19 to the DNCS 23. 
The DHCT 1 6 sends the client release request 1 19 after it has stopped using all resources for a session that it 
is attempting to tear down. The DNCS 23 receives the client release request 1 19 and initiates a MOD server 
release indication 121 to the VOD content server 22. The VOD content server 22 responds with a server 
release response 123 to the DNCS 23 which is then passed DHCT 16 in the form of a MOD client release 
confirm message 124. The network 18 does not release the resources provided for the session until the MOD 
server release response 123 is received from the MOD application server 19. 

-Page 12 } lines 23-31 

A MOD session tear down scenario may also be initiated by the DNCS 23. FIG. 4J is display 
$ jli^ diagram 140 of the DNCS 23 initiated session tear down scenario. In so doing, the DNCS 23 initiates a 

^~ server release indication message 142 to the VOD content server 22 providing the MOD session. The DNCS 

23 may also simultaneously release the client release indication message 144 to the DHCT 16 notifying the 
DHCT 16 of the tear down sequence. The VOD content server 22 that received the server release indication 
message 142 responds by a server release response message 146, and the DHCT 16 responds to the client 
release indication message 144 with a client release response message 148. The resources attributed or 
assigned to the MOD session are not released until both the client release response message 148 and the 
server release response message 146 are received by the DNCS 23. 



-Page 12, lines 32-37 through page 13, lines 1-10 



^ i )^) The VOD content server 22 provides an API by which the application servers can register interest 
Qjj $ in session setup and tear down events. Messages describing these events are sent to registered application 
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Y$~l servers and include the session ID and the user (application) data contained in the session setup request, 

QjfijtftJr* such as the MAC address of the DHCT 16 , the title ID, and the rental option in the case of the MOD 

application. In this way the MOD application server can be notified when a VOD session is established 
with the VOD content server 22 by the MOD application client 65. Additionally, the MOD application 
server 19 may use the API to request that the VOD content server 22 tear down the session if the user of 
the DHCT 16 is not authorized for the MOD service for billing reasons. The DHCT 16, the VOD content 
server 22, and the DNCS 23 may each initiate a session status scenario to determine the status of both the 
network and the other components described above. FIG. 4K is a display diagram 1 50 of a client initiated 
session status scenario. This procedure is used by DHCT 16 to query the DNCS 23 for the sessions that the 
DNCS 23 is maintaining for that DHCT 16. This procedure is also used to obtain detailed information about 
a session so that the DHCT 16 may re-establish a session after a reboot. The DCHT 1 6 initiates a client 
status request message 152 to the DNCS 23 to determine the status of the network 1 8. The DNCS 23 
responds with a client status confirm message 1 54 reporting the status to the DHCT 1 6. 



-Page 13, lines 18-27 



FIG. 4M is a display diagram of a network initiated client session status request 161 and a server 
(jfifO^ session status request 165. This procedure is used by the DNCS 23 to query a DHCT 16 for the sessions that 
are currently active. This procedure is also used to obtain detailed information about a session so the DNCS 
23 can determine if a session at the DNCS 23 is the same as the session maintained by the DHCT 16. In the 
client session status request scenario, the DNCS 23 initiates a client status indication message 162 to the 
DHCT 16 requesting status indication information. The DHCT 16 responds with a client status response 
message 164 to the DNCS reporting on the status of the MOD session. Similarly, the DNCS 23, in the server 
session status request 165, initiates a server status indication message 166 to the VOD content server 22. The 
VOD content server 22 responds with the status information in the form of a server status response message 
168 to the DNCS 23 reporting on its status. 



•Page 16, lines 7-11 



^ (Pj FIG. 8C is a display diagram of the MOD title catalog screen 197 configured as option two as 

(J)^^~*~ described above. In this non-limiting example, a description of the MOD title highlighted 201a in the current 
browse-by list 201 is shown in right portion of 204c. In this non-limiting example, selectable buttons 207 
may be included in the right portion 204c providing additional options to those shown in button bar 209. 
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-Page 16, lines 12-17 



f\ jO FIG. 8D is a display diagram of a title description screen 218 (option four) presented to the user upon 

(jQt^^ request from the MOD title catalog screen 197 in FIG. 8A. The title description screen 218 is a full screen 
view. In a center portion of the display 220, detailed descriptive information is presented. The user is 
presented a cancel option 221 which re-displays the MOD title catalog screen 197. If the title information is 
larger than that available on the screen, scrolling capability is provided via arrow input keys for the user to 
view the entire title information. 



-Page 19, lines 14-24 



^ ^ j Upon addition of a new MOD catalog or title category to the BFS server 28, the new files are 

£j2 Ps}LL> * immediately broadcast across the network 1 8 at intermittent intervals enabling the MOD application client 65 
on each DHCT 1 6 to receive the updated information. To notify the MOD application client 65 that new 
catalog files are available, the MOD application server 19 uses the DSM-CC 34 on the DNCS 23 to send a 
UDP pass-thru message to the MOD application client via the operating system of the DHCT 16. Each MOD 
application client, upon determining that a new catalog or an updated version is available, uses the BFS client 
43 (FIG. 3) in the DHCT 16 to download the files and store them in the MOD application client 65 database 
(not shown). The updated version of the files are implemented the next time the user activates the MOD title 
catalog screen 197. Alternatively, the MOD application client may chose to wait until the user activates the 
MOD service to load the most recent version of the MOD catalog for display at that time. 



-Page 20, lines 17-37 through page 21, lines 1-8 



Similarly, when new MOD titles are available for sale or release, a system operator adds the MOD 
titles to the MOD application server 19. The MOD application server 19 (FIG. 2) provides both a graphical 
user interface (GUI) and an API interface to install a MOD title asset onto the system. Typically this is done 
by, as a non-limiting example, inserting media such as a tape into the MOD application server 19 and using 
the graphical user interface (GUI) to define the meta-data about the title, but this process can be automated 
via the use of APIs (Application Programming Interfaces). The MOD title includes MPEG video assets for 
the title and optionally a trailer, as well as meta-data about the title. Meta-data includes but is not limited to 
data about the title, such as it's name, description, rating, directors, actors, length, etc. The MOD application 

. server 19 assigns a unique title ID and installs the added MOD titles to the VOD content server 22 by 
transferring title ID and MOD title MPEG content. The VOD content manager 21 adds the MPEG content to 
the VOD content servers 22. The MPEG content for each newly added MOD title may include not only the 
video (or other media), but may also include MPEG data for a trailer for the MOD title that may be later 

- included on.a .trailer ch.annel.prjn the MOD title catalog scr een 1 97 in portion 204a as described above. 
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-Page 21, lines 9-27 

Returning to FIG. 5, once the user navigates through the MOD title catalog screen 197 and chooses a 
MOD title for purchase, DHCT 16 presents the user a title purchase option, as shown in step 213. FIG. 10 is 
a display diagram of a rental option screen 227 as one embodiment of the title purchase option described in 
step 213 (FIG. 5). Descriptive information about the selected MOD title is shown to the user in a center 
portion of the display 228. Contained in this descriptive information is one or more "rental options": 
including both the rental period and rental price for the selected MOD title. In one rental option, the rental 
period may be the MOD title length — thereby requiring the user to immediately rent the MOD title and view 
it in its entirety at the time of rental. In another rental option, the rental period in the descriptive portion of 
the display 228 may be some integer multiplier of the MOD title length. As a non-limiting example, the 
rental period, as configured by the system operator at the headend 1 1 may be set to 2 times the MOD title 
length, so a two hour movie would enable a rental period of four hours. As yet another rental option, the 
rental period may be set to a specific period of time, such as a period of hours, days, or weeks. The price of 
the rental is included in the descriptive portion of the display 228 and may vary according to the popularity of 
the MOD title, the length of rental, and other variables as discussed in more detail below. Finally, if the user 
desires to rent the selected MOD title shown in the rental option screen 227 (FIG. 10), the user may depress a 
button on the remote 40 (FIG. 7) as directed in the rental option button bar 229. A cancel option may 
similarly be presented in the rental option button bar 229 that returns the user to the MOD title catalog screen 
197. If more than one rental option is provided for the title, the rental option screen 227 includes a scrolling 
list of rental options. 



-Page 22. lines 14-24 

As still yet another rental option, the user may have the option to change the language setting of the 
purchased MOD title to one of any other available languages from the default setting. The MPEG data 
stream of the MOD title as delivered to the DHCT 16 may include two or more language audio tracks such 
that the DHCT 16 may be configured to play an alternately chosen language according to the preference of 
the user. As a non-limiting example, a French speaking user may configure DHCT 16, by an interface (not 
shown) presented by the MOD application client 65, to present the purchased MOD title in French language 
audio as opposed to, for example, an English language default setting. Additionally, the DHCT 16 may, upon 
the user initially configuring the language, set the default for future presentations to the newly selected 
language. Alternatively, the MOD application client may access the language settings of the navigator 51 
(FIG. 3) and present all purchased MOD titles according to that language setting — provided the chosen 
language is one included in the MPEG audio track of the MOD title. 




-Page 22, lines 25-37 through page 23, lines J -9 

Once the user purchases a particular MOD title from the rental options screen 227 (FIG. 10) but prior 
to presentation of the title, the MOD application client 65 determines if the title is blocked by its particular 
rating, as shown in step 230 (FIG. 5). To determine if a particular MOD title is blocked because of its rating, 
the user should have previously entered a setting in the DHCT 16 defining what types of ratings would be 
acceptable for viewing. In the preferred embodiment this information is maintained by the resident navigator 
application and made available to other application clients via an application programming interface (API). 
The MOD application client 65 accesses the pre-configured rating parameters for comparison to the rating 
information contained in the catalog for the subject MOD title being purchased. As a non-limiting example, 
if a user configured the DHCT 16 to prevent any movie with an "R" rating from being viewed or purchased, 
the MOD application client 65 would not allow any movie with such rating to be purchased or viewed unless 
specifically overridden by the user. In this non-limiting example, parents may choose to block MOD titles 
with "R" ratings to prevent children from accessing the MOD titles while allowing the parents to access the 
blocked titles upon entry of a proper PIN. Thus, if the MOD application client 65 determines in step 230 that 
the selected MOD title is blocked by its rating, the application client 65 allows the user to unblock the title on 
a proper PIN entry, as shown in step 23 1 . In the preferred embodiment, the MOD application client 65 uses 
the "blocking PIN" number stored in the settings with the navigator 5 1 application. As such, a user can 
configure a single parental control PIN that is shared among applications. The user is allowed to escape or 
cancel from the PIN entry screen for overriding the title blocking according to rating, as shown in step 232. 
If the user chooses to escape the PIN entry screen or enters an improper or incorrect PIN, as shown in step 
233, the MOD application client 65 returns the user to the MOD title catalog screen 197 where the user 
reinitiates the MOD purchase sequence described above. 



-Page 26, lines 9-14 _ = — 

When the end of the MOD title is reached or the time allotted for viewing the MOD title has expired, 
the DHCT 16 presents the user with a message denoting that the rental period is over or that the MOD title 
has ended, as in step 260. FIG. 15 is a display diagram of the rental period end screen 260 presented to the 
user when the duration of the rental period has expired. Upon entering the cancel command through remote 
40 (FIG. 7) as instructed by the rental period end screen 260, the user returns to the MOD title catalog screen 
197 (FIG. 5). 



